@dsnopek Could you review this PR. I played with it on my Quest 2 and it seems to work fine.

I attempted to test this really quick but was getting an error about first_person_controller_vr.tscn being missing? But I don't think that has anything to do with this PR.

Just from skimming the code, this looks great!

I attempted to test this really quick but was getting an error about first_person_controller_vr.tscn being missing? But I don't think that has anything to do with this PR.

Just from skimming the code, this looks great!

This is because we have a dependency on the godot_openxr library for that scene. @BastiaanOlij can you think of any way of removing this dependency when it's a WebXR only situation?

Or maybe xr-tools should have it's own copy of the first person controller scene? This would come up with any other XR API as well.

Owh yeah, using the first_controller_person.tscn from the plugin is a convenience and also best practice for anyone targeting OpenXR, but it is not a requirement.

For a multi platform setup one could even argue that you don't want to go this way. There is nothing stopping us from just adding a normal ARVROrigin/ARVRCamera/ARVRController setup to the main scene and reproducing the initialisation script in the demo itself. It can then even be a script where a lot of overlapping things are used. You would end up with an init function like (Godot 3 pseudocode, I think this would be worth implementing in both 3 and 4):

var xr_interface : ARVRInterface

func _setup_for_openxr():
    ## do specific stuff for openxr
    ...

func _setup_for_webxr():
    ## do specific stuff for webxr
    ...

func _generic_setup():
    var vp = get_viewport()  
    vp.arvr = true

    ## Should obtain headset FPS in our _setup_for_xyz() functions and use that here but with a multiplier
    ## physics should really run at something like double the frame rate of the headset so lower margins become stable
    Engine.iterations_per_second = 90

func initialise() -> bool:
    xr_interface = ARVRServer.find_interface('OpenXR')
    if xr_interface and xr_interface.initialize():
        _setup_for_openxr()
        _generic_setup()
        return true

    xr_interface = ARVRServer.find_interface('WebXR')
    if xr_interface and xr_interface.initialize():
        _setup_for_webxr()
        _generic_setup()
        return true

    xr_interface = null
    return false

TBH at this point in time, I don't even mind that being part of the plugin

There are a few things the first_person_controller_vr.tscn from godot_openxr includes:

• The first_person_controller_vr.gd which you were mentioning above and includes passthrough enabling
• "configuration" which uses OpenXRConfig.gdns and provides:
  • View Configuration
  • Form Factor
  • Play Space Type
  • Action Sets
  • Interaction Profiles
• Controllers using controller.gd which hides the controllers when the tracking confidence drops to none

I'm guessing the "configuration" node might be necessary, but it also can't be present in the scene if it's a WebXR only version and godot_openxr hasn't been placed in the assets folder.

I assume what triggers Godot to actually use godot_openxr is the presence of the "godot_openxr.gdnlib" with the "singleton" option enabled.

I had to rework this pull request fairly heavily to support WebXR without having the godot_openxr asset present. The change includes a new StartXR node which can be added to the staging scene:

Note that the scene now has a standard ARVROrigin rather than using the godot_openxr FPController scene.

This node will detect both OpenXR and WebXR and start the appropriate interface. It has a few basic properties which we could extend later:

@dsnopek Could you try this again.

Works perfectly in my testing!

Skimming the diff, the rework seems great to me too :-)

I'm really liking this, I am wondering if we shouldn't go a little further and just add the logic into our staging scene in the plugin itself. The reason I didn't add the ARVROrigin node in there was because it would be possible to use it with different plugins, but seeing OpenXR and WebXR are really the only ones we'll likely use and we now have most of the logic in the plugin already anyway, might as well just put the whole thing in staging and make it really easy to use it.

Are there any use-cases where projects would want to start XR but not use the staging infrastructure?

We could move the StartXR and the ARVROrigin/camera/controllers into the plugin staging; so staging-based projects get it for free, but non-staging projects can drop in the StartXR node.

Are there any use-cases where projects would want to start XR but not use the staging infrastructure?

Personally, I don't always use the staging infrastructure when prototyping something simple, or just testing an individual scene.

We could move the StartXR and the ARVROrigin/camera/controllers into the plugin staging; so staging-based projects get it for free, but non-staging projects can drop in the StartXR node.

This sounds good!

I've updated the PR with moving the StartXR node as well as the ARVROrigin/camera/controllers into the base staging scene. This makes creating a customized staging scene significantly easier - in fact the base one will work unless the developer wishes to customize the prompt_for_continue and pause/resume logic.

The StartXR node is still available for projects which don't want to use staging.

Merged with Godot 4 equivalent functionality.